1. Field of the Invention
The invention relates to an improved UICC (Universal Integrated Circuit Card).
2. Description of the Related Art
A UICC is a smart card used in mobile equipments in order to authenticate a subscriber to a network operator. It is used in particular on GSM networks (the UICC then typically embeds a SIM application) or 3G Networks (such as UMTS, for which the UICC embeds a USIM application).
The expression mobile equipment (or ME) is defined in particular in the context of GSM or UMTS, but can be extended by analogy to any other mobile network technology. A mobile equipment is a terminal (e.g. cell phone, PDA, laptop computer, etc.), equipped with an emitter-receiver for radio communications with a base station of the mobile network (e.g. a BTS for GSM networks, a Node B for UMTS networks . . . ), which is able to manage radio resources, to establish communications and manage roaming, and which has a user interface. A mobile equipment associated with a UICC forms a mobile station. Normally a mobile equipment cannot establish any mobile communication without a UICC (but there is typically at least one exception: emergency numbers are usually always available). A mobile equipment is typically identified by a unique serial number (such as the IMEI, International Mobile Equipment Identity).
As explained for example on http://en.wikipedia.org/wiki/UICC, a UICC may contain several applications, and can therefore grant access to different networks (such as both GSM and UMTS networks), and also provide storage of a phone book and other applications. It is also possible to access a GSM network using an USIM application or to access UMTS networks using a SIM application if the mobile equipment is properly configured. The telephone book is typically a separate application and not part of either subscription information module. With UMTS release 5, a new application called ISIM (for “IP multimedia Services Identity Module”) is required for services in the IMS. The IMS (“IP Multimedia Subsystem”) is an architectural framework for delivering Internet Protocol (IP) multimedia services. It was originally designed by the wireless standards body 3rd Generation Partnership Project (3GPP), as a part of the vision for evolving mobile networks beyond GSM. Its original formulation (3GPP R5) represented an approach to delivering “Internet services” over GPRS. This vision was later updated by 3GPP, 3GPP2 and TISPAN by requiring support of networks other than GPRS, such as Wireless LAN, CDMA2000 and fixed line.
In a CDMA network, the UICC typically needs to contain a CSIM application, and can also contain 3GPP USIM and SIM applications in order to be able to be inserted into CDMA, GSM, or UMTS handsets, and connect to the network properly in all three cases.
In 2G networks, the SIM card and SIM application were bound together, and the expression “SIM card” referred to the physical card with the SIM application. In 3G networks, it is not very rigorous to speak of a USIM, CSIM, or SIM card, as all three are applications running on a UICC.
A UICC typically comprises a CPU, a few kilobytes of RAM, some ROM (or Flash) for the operating system, some EEPROM (or Flash) for storing data, and I/O circuits. A UICC typically has no power supply (no battery, etc.) but instead receives energy from the mobile equipment. Consequently the UICC typically has no time reference (whenever the UICC is powered down by the mobile equipment, it typically loses its RAM contents and it totally stops working until it is powered up again). Therefore when the UICC wishes to take an action which involves time, date, or measurement of durations, it typically has to rely on the mobile equipment (which needs to provide the requested information). The first UICC were big (usually 85×54 mm) smart cards. Current ones are smaller (typically 25×15 mm, or even less). The UICC formats being standardized, a subscriber can easily move a UICC from one mobile equipment to another, and accordingly transfer the mobile network account to the other mobile equipment.
The use and contents of a UICC can be protected by use of PIN codes. One code, PIN1, can be defined to control normal use of the mobile equipment. Another code, PIN2, can be set, to allow the use of special functions (like limiting outbound telephone calls to a list of numbers). Unblocking codes (called PUK1 and PUK2) can be used to reset the PIN codes (PIN1 and PIN2 respectively).
Historically, UICC were “slave” devices, in the sense that a master device (typically the mobile equipment) was the one deciding when to send a command to the UICC. The UICC was only able to execute what it was requested to execute, and at the time defined by the master. However this became unpractical in certain situations. Indeed, the UICC may have to interact with the subscriber, while it typically has no screen, no keyboard, and more generally no user interface. It is therefore beneficial for the UICC to have the possibility to use the user interfaces of the mobile equipment. In some instance it is desirable for the UICC to behave as a master and send “orders” to the mobile equipment. To that end, a technology usually referred to as “SIM Application Toolkit” (SAT), was developed in the nineties, and was originally standardized in particular in GSM 11.14 (“Specification of the SIM Application Toolkit (SAT) for the Subscriber Identity Module—Mobile Equipment (SIM-ME) interface”). More recent standard linked to the emergence of 3G networks comprise in particular ETSI TS 102 221 (“Smart Cards; UICC-Terminal interface; Physical and logical characteristics”) and ETSI TS 102 241 (“Smart Cards; UICC Application Programming Interface (UICC API) for Java Card™”), and do not fundamentally change the SAT technology. The principle is that the UICC can embed a toolkit applet which informs the mobile equipment that it wishes to send a command (called proactive command, because it does originate from the UICC itself and not from the mobile equipment, which is the master). The mobile equipment can then retrieve the proactive command, execute it, and send the results to the UICC. This is explained in particular in ETSI TS 102 221 V8.2.0 (2009-06), page 49, paragraph 7.4.2.1 (“Proactive command”), which states that when the UICC has a pending proactive command that it wishes to send to the mobile equipment (called the terminal in this context), it can, next time it receives a command APDU (noted C-APDU), return in the response APDU (noted R-APDU), instead of the status word 9000 (which means that the C-APDU was carried out properly), a special status word 91XX. Therefore, when the mobile equipment receives a status word 91XX instead of 9000, it knows that it has to retrieve a proactive command from the UICC, and that the proactive command is coded on XX bytes. The mobile equipment can retrieve the proactive command by sending to the UICC an APDU called “FETCH”. The FETCH APDU is standardized (the class is 80, and the instruction is 12). The mobile equipment can then execute the proactive command (which can be a command to display a menu, to request a keyboard input, etc.). Once the proactive command is executed, the mobile equipment can send an APDU called “TERMINAL RESPONSE” (standardized as well, with a class 80 and an instruction code 14), in order to provide the output of the proactive command to the UICC. As explained in particular in ETSI TS 102 241 V8.0.0 (2008-06), page 19 paragraph 6.4 (“Proactive command handling”), it has been decided to centralize the management of the proactive commands (management of the special 91XX status words, of the FETCH APDUs and TERMINAL RESPONSE APDUs . . . ) in the CAT runtime environment. Therefore the CAT runtime environment can manage the toolkit protocol on behalf of the toolkit applets. The toolkit applets do not need to worry about this protocol aspect. Instead, the toolkit applet can simply call a method called SEND in the standard TS 102 241. The SEND method is part of the uicc.toolkit.ProactiveHandler API and is defined as follows:
byte send ( )
                throws ToolkitException        
Sends the current Proactive command.
Returns:
general result of the command (first byte of Result TLV in Terminal Response)
Throws:
ToolkitException—with the following reason codes:                UNAVAILABLE_ELEMENT if the Result Comprehension TLV is missing.        OUT_OF_TLV_BOUNDARIES if the general result byte is missing in the Result Comprehension TLV.        COMMAND_NOT_ALLOWED if the Proactive command to be sent or one of its parameter is not allowed by the CAT Runtime Environment.        
A difference between Java Card™ applets and a toolkit applets is that toolkit applets do not handle APDUs directly. Toolkit applets can handle higher level messages, e.g. thanks to the SEND method. The execution of the SEND method can span over multiple APDUs (the proactive protocol commands: FETCH, TERMINAL RESPONSE). A toolkit applet can also be triggered by an event to which it has registered. The application triggering portion of the CAT Runtime Environment is responsible for the activation of Toolkit applets, based on the APDU received by the UICC. A Translator of the CAT Runtime Environment translates the received APDUs into events, which are passed to a triggering entity. The triggering entity checks the toolkit registry in order to see which toolkit applet (if any) registered to the corresponding event, and accordingly it triggers the corresponding toolkit applet.
This mechanism is used for example in prepaid UICC subscriptions. A prepaid UICC typically decrements a counter at regular intervals (e.g. every second) after a communication has been established, and when the counter reaches zero, it is no longer possible to communicate (the subscriber needs to purchase new credits). Unfortunately, the UICC is in general not able to measure time and relies on the mobile equipment. The UICC typically registers to a timer expiration event. Consequently, when the timer expires in the mobile equipment, a toolkit applet is automatically triggered in the UICC and decrements the subscription counter accordingly.
Since a UICC is a security device, it often needs to communicate securely with a third party. The standard TS 102 484, which latest version is V7.5.0 (2009-10), entitled “Smart Cards; Secure channel between a UICC and an end-point terminal” specifies the technical implementation of the secure channel requirements specified in TS 102 412 (C.F. in particular page 18, paragraph 4.5 “Secure channel to secure local terminal interfaces” of ETSI TS 102 412 V9.1.0, 2009-06). TS 102 484 specifies four types of secured data transport protocols:                TLS—Application to Application        Secured APDU—Application to Application        IPsec—USB class to USB class        Secured APDU—Platform to Platform        
For the last one (Secured APDU—Platform to Platform), TS 102 484 specifies (page 22, paragraph 9) that “The Platform to platform APDU channel shall only be set up on logical channel 0, and while a platform to platform secure channel is active, the UICC shall reject APDUs on any other logical channel. It shall be possible to use logical channels in the encrypted APDU payload”. At the same time an Application to Application—APDU Secure channel cannot secure proactive commands (sent on logical channel 0 according to the standard) as it can only secure a non-0 logical channel, i.e. any logical channel except logical channel 0.
It turns out that with current versions of the standards, the only way to secure proactive commands consists in systematically encrypting all communications between the UICC and the mobile equipment. This is very inconvenient (the execution is slower, and some information which is not necessarily sensitive ends up being encrypted anyway), but it is a constraint of the current standard (TS 102 484).